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"Time  is  what  we 
want  most  but  what 
we  use  worst." 
—William  Penn 


As  William  Penn  noted  centuries  ago,  time  might  be  our  most  precious  resource  but 
it  is  also  one  that  we  have  trouble  managing  effectively.  While  cost-performance 
trade-offs  get  a  lot  of  emphasis  in  developmental  acquisition  efforts,  schedule  or 
cycle  time  is  also  an  important  part  of  the  cost-schedule-performance  triad  that 
determines  outcomes.  Note  that  the  terms  "cycle  time"  and  "schedule"  will  be  used 
interchangeably  in  this  article  to  mean  the  total  time  required  from  program  initiation  until  Initial 
Operational  Capability  (IOC). 

Acquisition  cycle  time  continues  to  be  a  "hot  topic."  Over  years,  many  have  argued  that  it  simply  takes  too  long 
to  get  capability  to  the  warfighter  and  that  fundamental  reform  is  needed  to  address  this  issue.  More  recently, 
we  see  the  imperative  to  deploy  capabilities  faster  in  light  of  cyber  and  asymmetric  threats.  Several  studies  have 
validated  this  notion  that  it  is  taking  longer  now  than  in  past  decades  to  develop  and  field  Department  of  Defense 
(DoD)  weapon  systems.  Despite  all  the  attention  and  reforms,  the  issue  has  not  gone  away.  In  fact,  it  may  even 
be  more  problematic  now  than  in  the  past  because  of  program  complexity,  use  of  new  and  advanced  materials, 
software-intensive  designs,  advanced  manufacturing  techniques  and  many  other  factors. 


Schultz  is  a  professor  of  program  management  at  the  Defense  Acquisition  University's  Mid-Atlantic  Region  in  California,  Md. 
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A  DoD  Inspector  General  audit  report  (No.  D-2002-032, 
Dec.  28, 2001)  identified  that  in  1960  major  defense  acqui¬ 
sition  programs  (MDAPs)  required  seven  years  for  comple¬ 
tion,  again  defined  as  program  start  to  IOC.  In  1996,  this 
metric  had  grown  to  11  years.  A  more  recent  Government 
Accountability  Office  study  (GAO-14-145T)  highlighted  that 
the  average  delay  in  achieving  IOC  on  MDAPs  had  grown 
from  22  months  in  2008  to  27  months  in  2012  while  cost 
growth  increased  from  $323  billion  to  $411  billion.  Although 
the  purpose  of  this  discussion  is  not  to  examine  the  history 
or  causes  of  acquisition  cycle  time  growth,  it  is  important 
to  understand  why  there  is  such  an  emphasis  on  schedule 
and  getting  capability  to  the  warfighter  more  rapidly. 

Cycle  time  can  be  addressed  in  the  context  of  "micro"  and 
"macro"  perspectives.  Micro-cycle  time  is  defined  here  as  the 
specific  program  schedule  tasks  and  dependencies  necessary 
to  get  a  capability  fielded,  based  on  the  program's  unique  tech¬ 
nical  and  programmatic  aspects.  Thus,  it  is  addressed  in  the 
context  of  a  specific  program  and  is  the  responsibility  of  the 
program  manager  (PM)  to  plan  and  execute— including  any 
programmatic  assumptions,  constraints  and  logic. 


reasonable  risks.  The  "will"  and  "shall"  statements  in  the  regu¬ 
latory  guidance  do  not  necessarily  override  the  mandate  for 
a  tailored  approach.  So,  even  if  one  is  not  using  an  acceler¬ 
ated  model,  opportunities  to  accelerate  the  program  schedule 
should  be  explored. 

Both  macro-  and  micro-cycle  time  aspects  should  be  ad¬ 
dressed  as  part  of  the  overall  risk-  and  opportunity-manage¬ 
ment  framework.  The  following  discussion  provides  some 
examples  of  cycle-time  risks  and  opportunities  based  on  my 
experiences.  A  robust  and  continuous  approach  to  assessing 
and  managing  schedule  risks  and  opportunities  can  be  very 
useful  in  getting  to  a  successful  acquisition  outcome  and  help 
answer  the  question,  "What  can  we  do  to  reduce  cycle  time?" 

Risks 

Schedule  logic  and  assumptions:  PMs  typically  build  a  Gov¬ 
ernment  Roadmap  Schedule  and  an  Integrated  Master  Plan 
(IMP)  that  outline  the  overall  schedule  for  the  program  and  key 
events  and  criteria  to  complete  the  events.  The  IMP  and  Gov¬ 
ernment  Roadmap  Schedule  provided  to  the  contractor  may 
include  hard  dates  that  contractors  must  meet.  These  program 


Implementing  concurrent  efforts  and/or  eliminating 


some  tasks  are  often  used  to  enable  this  rapid 
approach,  recognizing  that  risk  and  pro^am 
inefficiencies  may  increase.  .  ^ 


On  the  other  hand,  macro-cycle  time  is  defined  as  the  impact 
that  the  overall  acquisition  management  and  decision-support- 
system  structures  have  on  the  time  it  takes  to  field  a  capability 
from  Milestone  B  to  IOC.  For  example,  macro-cycle  time  con¬ 
siderations  would  include  time  necessary  for  the  processes  and 
approvals  within  the  DoD  decision-support  systems. 

Macro-cycle  time  considerations  are  addressed  in  statutory, 
regulatory  and  policy  documents  such  as  the  new  interim  DoDI 
5000.02.  Note  that  the  new  5000.02  Instruction  includes  an 
Accelerated  Acquisition  Program  model,  where  schedule  con¬ 
siderations  override  other  programmatic  constraints.  Imple¬ 
menting  concurrent  efforts  and/or  eliminating  some  tasks  are 
often  used  to  enable  this  rapid  approach,  recognizing  that  risk 
and  program  inefficiencies  may  increase. 

Another  aspect  of  macro-cycle  time  considerations  in  the 
5000.02  is  tailoring  each  program  based  on  the  unique  as¬ 
pects  associated  with  it.  The  Accelerated  Acquisition  Program 
model  is  called  out  as  one  specific  example  of  tailoring,  and 
many  others  are  possible.  The  basic  premise  suggests  that 
PMs  should  look  for  opportunities  to  structure  their  programs 
in  a  manner  that  reduces  time  and  cost,  while  accepting 


constraints  are  then  used  as  the  basis  for  the  contractor-devel¬ 
oped  Integrated  Master  Schedule  (IMS)  that  establishes  dates 
and  schedule-task  relationships  for  the  program  execution. 

In  a  competitive  environment,  companies  may  be  reluctant 
to  identify  an  overly  aggressive  schedule  as  high  risk  since 
this  could  jeopardize  their  competitive  positions.  PMs  should 
encourage  open  dialogue  with  industry  in  the  pre-award  plan¬ 
ning  stage  to  assess  the  amount  of  time  needed  to  complete 
the  planned  work  and  to  validate  schedule  assumptions  before 
contract  award.  If  we  decide  to  take  on  a  high-risk  schedule,  at 
least  we  can  manage  it  as  such  and  ensure  actions  are  planned 
to  address  contingencies  if  the  risks  are  realized. 

The  logic  associated  with  the  schedule  relationships  should 
also  be  carefully  reviewed  and  periodically  revisited.  This  logic 
can  be  flawed  and  change  overtime  as  we  learn  more  and  bet¬ 
ter  understand  the  schedule  interrelationships.  It  may  also  be 
wise  to  keep  the  complexity  at  a  manageable  level. 

I  learned  this  lesson  while  managing  a  software-intensive 
program.  We  decided  to  create  a  very  detailed  master  sched¬ 
ule  with  multiple  supporting  subschedules  that  linked  and 
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automatically  updated  the  master  schedule  if  all  the  inputs 
were  entered  correctly.  The  effort  was  well  intentioned  as 
the  program  involved  a  large  team  of  developers  and  engi¬ 
neers  working  concurrently  on  several  modules.  However, 
the  schedule  and  subschedules  became  so  complicated  and 
difficult  to  manage  that  they  became  unusable.  We  ended  up 
reverting  to  a  simpler  schedule  that  provided  enough  over¬ 
sight  to  keep  on  top  of  key  tasks  and  actual  progress.  We  also 
adjusted  the  schedule  several  times  based  on  the  knowledge 
of  developer  velocity  and  features  that  could  be  descoped 
and/or  deferred. 

Use  of  Commercial  Off-the-Shelf  (COTS)  products:  Using 
COTS  offers  many  benefits  and  is  prescribed  in  DoD  Directive 
5000.01  as  the  preferred  approach  to  satisfying  user  needs. 
COTS  can  also  present  risks  to  a  program  and  has  been  at  the 
heart  of  significant  cost  and  schedule  delays  within  DoD.  The 
issue  has  not  been  the  COTS  product  itself  but  rather  attempts 
to  modify  it  and/or  not  fully  understanding  the  COTS  product. 

A  Dec.  23,  2013,  Reuters  article,  "Why  the  Pentagon's  ac¬ 
counting  fixes  end  up  broken,"  highlighted  a  common  thread 
of  several  failed  Enterprise  Resource  Planning  (ERP)  projects. 
A  COTS  product  is  chosen  for  an  ERP  solution  but  is  then 
modified  to  reflect  the  legacy-system  business  model.  These 
COTS  modifications  create  a  unique  software  product  that  is 
no  longer  COTS  and  becomes  difficult  to  maintain.  Further¬ 
more,  the  benefits  of  COTS— such  as  the  ability  to  leverage 
upgrades,  training  and  support— can  be  lost. 

Years  ago,  I  observed  an  ERP  system  implementation  that 
encountered  this  exact  model.  The  modified  COTS  software 
worked  and  passed  the  acceptance  tests  but  never  was  imple¬ 
mented  by  the  customer  due  to  the  issues  associated  with 
maintaining  it.  Other  programs  apparently  have  learned  this 
same  lesson  and  the  word  is  out  that,  if  you  decide  to  use 
COTS,  you  need  to  adopt  the  business  process  model  it  is 
based  on  rather  than  try  to  keep  your  existing  processes  in 
place  as  part  of  the  COTS  implementation. 

For  hardware,  COTS  can  also  present  some  risks.  Many  pro¬ 
grams  use  COTS  computers  and  servers,  even  as  part  of  their 
mission-computing  design.  Since  these  items  can  quickly  be¬ 
come  obsolete  and  no  longer  supported  by  the  original  manu¬ 
facturer,  PMs  should  plan  appropriate  mitigations,  including 
the  use  of  periodic  technology  updates. 

Inadequate  planning:  The  imperative  to  accelerate  can  back¬ 
fire  and  actually  be  counterproductive  if  not  planned  and  man¬ 
aged  properly.  A  good  example  is  the  use  of  Undefinitized  Con¬ 
tract  Actions  (UCAs)  to  accelerate  the  start  of  development. 
On  the  surface,  one  might  expect  a  faster  overall  schedule 
since  it  avoids  the  often  lengthy  upfront  process  of  proposal 
development  and  negotiations  before  work  starts.  However, 
according  to  the  Under  Secretary  of  Defense  for  Acquisition, 
Technology,  and  Logistics'  2013  Annual  Report  on  the  Perfor¬ 
mance  of  the  Defense  Acquisition  System,  UCAs  are  identified  as 


contributors  to  costand  schedule  growth  in  DoD  development 
contracts.  UCAs  were  not  correlated  with  cost  and  schedule 
growth  in  early  production. 

Another  example  is  rushing  the  contracting  cycle  to  stay  on 
schedule.  This  often  starts  with  the  release  to  industry  of  the 
request  for  proposal  (REP).  Given  the  lead  time  involved  in 
contracting  cycles,  the  temptation  can  arise  to  accelerate  the 
REP  development  and  release,  bypassing  internal  reviews  and/ 
or  skipping  a  draft  RFP  release  for  industry  comment.  Some 
might  refer  to  this  behavior  as  schedule  driven  versus  event 
driven,  as  detailed  in  Dr.  Mark  Husband's  March-April  2014 
Defense  AT&L  article,  "Schedule  or  Event  Driven?" 

Every  time  I  have  tried  to  accelerate  an  RFP  release,  it  ended 
up  costing  more  time  to  correct  issues  such  as  inconsistencies 
or  lack  of  clarity  in  RFP  requirements.  Industry  will  provide 
valuable  feedback  in  a  draft  RFP  that  will  often  help  the  gov¬ 
ernment  team  develop  a  better  final  RFP  that  can  avoid  future 
perturbations.  While  I  don't  have  any  data  to  back  it  up,  my 
experience  suggests  that  a  very  robust  acquisition  strategy 
and  RFP  planning  effort  saves  time  in  the  overall  schedule  and 
helps  DoD  get  better  outcomes. 

Opportunities 

Concurrency:  I  had  a  great  experience  working  an  aircraft 
mission-system  upgrade  program  that  employed  a  concurrent 
development  and  production  strategy  to  accelerate  the  cycle 
time  for  fielding.  While  this  strategy  was  risky,  the  risks  were 
identified  and  managed  jointly  by  the  contractor  and  govern¬ 
ment  team  in  a  robust  and  transparent  manner.  When  the 
program  was  planned,  we  expected  that  the  software  design 
would  require  several  builds  and  iterations  after  a  series  of 
both  ground  and  flight  test  events. 

Meanwhile,  the  hardware  designs  were  expected  to  be  stable 
since  we  were  integrating  proven  avionics,  sensors  and  com¬ 
munication  subsystems.  A  concurrent  strategy  was  adopted, 
but  only  after  careful  analysis  of  the  program  plan,  schedule 
and  technical  risks. 

The  teamwork  and  commitment  of  the  joint  DoD-contractor 
team  played  a  big  role  in  the  success.  Despite  some  bumps 
along  the  way,  we  delivered  the  capability  within  budget  and 
on  schedule.  Note  that  due  to  the  risks  of  this  approach,  a 
concurrent  strategy  is  likely  to  get  significant  scrutiny  and 
should  be  used  only  where  all  the  right  conditions  are  in 
place.  These  conditions  include  the  right  expertise,  adequate 
resources  (both  human  and  financial),  risks  that  are  assessed 
as  no  higher  than  moderate,  and  buy-in  from  the  entire  team, 
including  top  management  of  the  DoD  and  contractor  teams. 

Schedule  is  an  important  message:  It  may  seem  an  over¬ 
simplification  but  sending  a  message  to  appropriate  stake¬ 
holders,  including  the  contractor,  that  schedule  is  important 
should  not  be  overlooked.  While  cost-performance  trades 
continue  to  get  a  lot  of  emphasis,  how  about  addressing 
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schedule-performance  and  cost-schedule  trades  similar  to 
the  Agile  methodology  in  developing  software?  Note  that  one 
of  the  tenets  of  Agile  software  development  methodology  is 
that  features  will  be  managed  as  a  variable  in  a  given  build  but 
schedule  and  cost  will  remain  fixed.  This  tenet  is  based  on  the 
idea  that  missing  a  delivery  date  will  create  greater  overall 
dissatisfaction  and  impact  than  deferring  some  functionality 
until  a  later  build. 


have  learned  and  what  we  can  improve.  Cycle-time  reduction 
will  be  difficult  to  achieve  without  an  organizational  culture  of 
identifying  and  managing  those  opportunities. 

Challenging  the  status  quo  and  creating  an  environment  where 
performance  is  rewarded  can  enable  schedule  compression 
opportunities.  A  few  years  ago,  I  worked  on  an  urgent  program 
to  get  a  radar  system  installed  in  Iraq.  When  we  looked  at  the 


Challenging  the  status  quo  and  creating 
an  environment  where  performance 
is  rewarded  can  enable  schedule 
compression  opportunities. 


Another  practice  involves  setting  clear  expectations  at  the  be¬ 
ginning  of  a  new  contract.  Assuming  a  fixed-price  type  con¬ 
tract,  it  should  be  clear  that  missing  a  contract  deliverable  date 
is  a  serious  breach.  What  some  may  not  realize  is  that  if  the 
government  allows  schedule  slips  without  consequences,  the 
message  is  clear— that  schedule  is  not  important. 

I  once  was  told  by  a  senior  contracting  official  that  accepting 
several  late  deliveries  and  then  deciding  to  take  action  after 
the  fact  is  too  little,  too  late.  It  is  the  equivalent  of  saying  that 
schedule  is  not  important.  Rather,  the  message  should  be  clear 
that,  if  the  contractor  expects  to  miss  any  contractual  delivery 
date,  notice  is  to  be  given  before  the  slip  occurs  accompanied 
with  an  explanation  and  get-well  plan.  This  enables  the  two 
parties  to  discuss  and  attempt  to  resolve  the  issue  before  the 
slip  and  lets  the  contractor  know  that  we  expect  performance 
in  accordance  with  the  contract.  Appropriate  corrective  ac¬ 
tions  and  contractual  remedies  also  can  be  considered.  Finally, 
the  contractor's  performance  will  be  documented  in  the  Con¬ 
tractors'  Performance  Assessment  Report,  which  can  be  an 
important  factor  in  future  source  selections. 

Program  teams  have  several  tools  to  help  manage  the  schedule 
and  assess  opportunities  to  accelerate.  Some  companies  are 
using  the  theory  of  constraints  (originated  by  Eli  Goldratt,  au¬ 
thor  of  the  book  The  Goal)  as  a  basis  for  lean  project  manage¬ 
ment  and  lean  manufacturing  techniques  to  drive  accelerated 
schedules  and  cost  reductions.  PMs  need  to  understand  what 
methodology  their  industry  counterparts  are  using  and  why 
they  believe  it's  appropriate. 

Challenge  the  status  quo:  There  is  an  old  adage  that  goes 
something  like  "the  schedule  will  expand  to  fit  what  we 
planned  (even  if  we  learn  we  can  do  it  faster)."  This  humorous 
saying  highlights  an  important  opportunity  when  assessing  a 
program  schedule  and  looking  for  ways  to  get  it  done  faster. 
The  opportunity  is  to  take  a  look  at  what  we  are  doing,  what  we 


normal  production  lead  time  to  get  the  radar  produced  and 
fielded,  it  was  impossible  to  meet  the  need  date.  The  project 
manager  suggested  that  we  tell  the  user  we  could  not  meet 
its  requirement. 

We  then  brainstormed  and  asked  if  the  radar  was  currently  in 
production  and  if  we  could  divert  another  user's  delivery  with 
payback  from  the  system  we  ordered.  Sure  enough,  one  of  the 
users  was  happy  to  divert  its  planned  delivery,  enabling  us  to 
meet  the  compressed  timeline.  We  also  had  to  accelerate  and 
combine  some  site-activation  efforts  and  enlist  support  from 
other  agencies  to  help  us  obtain  access  and  eventual  safety 
and  accuracy  certifications. 

On  another  program,  I  observed  an  industry  PM  question 
why  we  needed  so  much  documentation  as  part  of  a  draft 
RFP.  The  documentation  in  question  related  to  COTS  items 
where  a  lengthy  review  of  specifications  added  no  value.  This 
simple  suggestion  saved  a  lot  of  time  and  effort  on  work  that 
the  previous  teams  always  did. 

Conclusion:  Cycle  time  is  one  of  the  key  pillars  of  acquisition 
and  has  direct  links  and  impacts  to  other  programmatic  el¬ 
ements.  PMs  must  navigate  through  both  macro  and  micro 
aspects  of  cycle-time  risk  and  opportunities.  The  imperative 
to  field  systems  and  solutions  quicker  is  challenging  and  will 
probably  become  more  so,  given  the  threat  environment  and 
pace  of  new  technology.  PMs  should  create  an  environment 
and  expectation  that  cycle  time  is  important  in  all  aspects  of 
acquisition  processes  and  tasks,  while  ensuring  credible  ex¬ 
ecution  to  the  baseline  schedule! 

All  this  cycle-time  talk  reminds  me  of  the  user  who  said  to 
me:  "We  needed  this  capability  yesterday.  Why  does  it  take 
so  long?"  ^ 


The  author  can  be  contacted  at  brian.schultz(S)dau.mil. 
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